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REMARKS/ARGUMENTS 
1. Claim Rejections - 35 U.S.C. § 103 (a) 

Claims 22-31 and 37-42 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Burns et al. (U.S. 6,018,747, hereafter Burns), in view of Blandford 
(U.S. 6,470,449, hereafter Blandford). In this Office Action, the Examiner stated: 

In response to applicant's arguments filed 02/09/2009, the 
arguments have been considered but are deemed moot in light of the new 
grounds of rejection presented above which was necessitated by 
amendment. 

Although the Ferrat is no longer cited as a reference, the Office Action is replete 
with references to sections of Ferrat. To the extent Applicant is able to discern the 
Examiner's reasoning in issuing the rejection, Applicant respectfully traverses the 
rejection. Applicant notes that Burns discloses a delta update technique. It contains a 
number of steps which leads to a delta file that consists of two types of commands: 
COPY and ADD. The COPY command reuses code already present in the old version, 
while it adds new data to be included in the delta file. So in order to make the smallest 
possible delta file, the goal of Burns is to use as many COPY commands and as few 
ADD commands as possible. 

However, in a situation such as that addressed by the present invention, when 
part of the installed version is corrupted, for example, due to a faulty memory or virus, 
the type of delta file disclosed in Burns cannot be used. In Burns, the delta file is 
created with the assumption that the installed version is identical to the version used for 
creating the delta file. Applying such a delta file to a corrupt image would render the 
device inoperable. To overcome the disadvantage of Burns, which is not disclosed or 
suggested by Burns in combination with Ferret and Blandford, is to detect all damaged 
blocks in the installed version and use this information to create a tailor-made delta 
update file. The algorithm for creating a tailor-made delta differs from the conventional 
method of determining the best combination of ADD and COPY commands. For a tailor- 
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made version a restrictive COPY command must be used so as to avoid reusing corrupt 
blocks. Neither Ferrat nor Blandford fail to overcome the deficiencies of Burns. 
Considering the operation of Burns, the use of a checksum in Blandford is irrelevant. 
Because Burns is not directed to finding corrupted portions of memory, using the 
checksum of Blandford is superfluous. It is similar to adding a warning indicator 
(Blandford) to a fail-safe system (Burns). 

Further, unlike Ferrat, the present invention does not work on tables in a 
database, but directly on the flash memory (as claimed) where it updates the image of 
the stored data "in-place". A delta update in the present invention means that it does not 
transfer the complete image, and, more importantly refers to the fact that it reuses and 
reorganizes the data already on the flash memory of the mobile terminal through a 
series of steps transforming the existing image into the updated one. 

It is impermissible to use hindsight to read back into the prior art, the teachings of 
the present application. In other words, independent claims 22 and 37-40 have been 
used as a blueprint to pick and chose elements from the prior art similar to the claim 
limitations therein, without regard to the manner in which those limitations have been 
combined to effect a novel and useful improvement to the state of the art. 

Claims 32-36 stand rejected under 35 U.S.C. 103(a) as being unpatentable over 
Burns, in view of Blandford and in further view of Kocher et al (US 6,289,455 hereafter 
Kocher). In this Office Action, the Examiner stated: 

In response to applicant's arguments filed 02/09/2009, the 
arguments have been considered but are deemed moot in light of the new 
grounds of rejection presented above which was necessitated by 
amendment. 

Although the Ferrat is no longer cited as a reference, the Office Action is replete 
with references to sections of Ferrat. To the extent Applicant is able to discern the 
Examiner's reasoning in issuing the rejection, Applicant respectfully traverses the 
rejection. Applicant notes that Burns discloses a delta update technique. It contains a 
number of steps which leads to a delta file that consists of two types of commands: 
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COPY and ADD. The COPY command reuses code already present in the old version, 
while it adds new data to be included in the delta file. So in order to make the smallest 
possible delta file, the goal of Burns is to use as many COPY commands and as few 
ADD commands as possible. 

However, in a situation such as that addressed by the present invention, when 
part of the installed version is corrupted, for example, due to a faulty memory or virus, 
the type of delta file disclosed in Burns cannot be used. In Burns, the delta file is 
created with the assumption that the installed version is identical to the version used for 
creating the delta file. Applying such a delta file to a corrupt image would render the 
device inoperable. To overcome the disadvantage of Burns, which is not disclosed or 
suggested by Burns in combination with Ferret, Blandford and Kocher, is to detect all 
damaged blocks in the installed version and use this information to create a tailor-made 
delta update file. The algorithm for creating a tailor-made delta differs from the 
conventional method of determining the best combination of ADD and COPY 
commands. For a tailor-made version a restrictive COPY command must be used so as 
to avoid reusing corrupt blocks. Ferret and Blandford fail to overcome the deficiencies 
of Burns. Considering the operation of Burns, the use of a checksum in Blandford is 
irrelevant. Because Burns is not directed to finding corrupted portions of memory, using 
the checksum of Blandford is superfluous. It is similar to adding a warning indicator 
(Blandford) to a fail-safe system (Burns). 

Further, unlike Ferrat, the present invention does not work on tables in a 
database, but directly on the flash memory (as claimed) where it updates the image of 
the stored data "in-place". A delta update in the present invention means that it does not 
transfer the complete image, and, more importantly refers to the fact that it reuses and 
reorganizes the data already on the flash memory of the mobile terminal through a 
series of steps transforming the existing image into the updated one. 

It is impermissible to use hindsight to read back into the prior art, the teachings of 
the present application. In other words, claims 32-38 have been used as a blueprint to 
pick and chose elements from the prior art similar to the claim limitations therein, 
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without regard to the manner in which those limitations have been combined to effect a 
novel and useful improvement to the state of the art. 



In view of the foregoing remarks, the Applicant believes all of the claims currently 
pending in the Application to be in a condition for allowance. The Applicant, therefore, 
respectfully requests that the Examiner withdraw all rejections and issue a Notice of 
Allowance for all pending claims. 

The Applicant requests a telephonic interview if the Examiner has any questions 
or requires any additional information that would further or expedite the prosecution of 
the Application. 



Date: August 12. 2009 
Ericsson Inc. 

6300 Legacy Drive, M/S EVR 1-C-1 1 
Piano, Texas 75024 
(972) 583-4145 

michael.cameron@ericsson.com 



CONCLUSION 




Michael Cameron 
Registration No. 50,298 
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